[レポート]EC サイトのレガシーマイグレーション #AWSSummit

[レポート]EC サイトのレガシーマイグレーション #AWSSummit

Clock Icon2015.06.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

森永です。

AWS Summit Tokyo 2015MC-01: Mid-Range Customers:「EC サイトのレガシーマイグレーション」のレポートです。

スピーカーは株式会社サードウェーブソリューションズの大坂 芳弘氏です。

レポート

ECサイトをAWSに移行する経緯

ドスパラの通販サイトのHW期限切れ 最初はHWリプレースを予定していた
経営陣から「リプレースだけなのになんでこんなにかかるの?」「AWSって考えてないの?」というプレッシャー
開発メンバーから「PCの組み立てを生業にしているのにクラウド?」「セキュリティ大丈夫?」という疑問や不安
→AWSに調査開始

オンプレとAWSの比較

比較項目 オンプレの場合 AWSの場合
緊急時のリソース追加 できない できる
調達時間 1ヶ月〜2ヶ月 即時
HW障害 システム停止 考慮不要
障害対応時間 かけつけ4時間 考慮不要
人的リソース 保守要員が必要 考慮不要
DR 複数のDCに2重化 複数リージョン配置
初期コスト 調達機器に併せて発生 なし
追加コスト 調達機器に併せて発生 サービスを追加する際にランニングコストが増加
ランニングコスト データセンタ使用料+保守費用 サービスの利用料から従量課金
HWリプレイス 概ね5年毎 考慮不要

→オンプレと比較してメリットが有る

AWS移行時の課題と対策

・技術面
レスポンス問題
 AWSとDC(基幹システム)をつないだ際に応答速度は大丈夫か
 →AWSと基幹システムをDXで接続
レガシーアプリケーション問題
 OS・ミドルのバージョン変更による影響はどれくらいあるか。アプリケーションの改修範囲は?
 →OS、Oracle、PHPに分類して調査
  →OSとOracleについてはバージョンでの影響はほぼなし。
  →PHPは影響があった。→セキュリティを考慮した上で最低限のバージョンアップをして影響範囲を最小化
データ移行問題
 システム切替時の停止時間に関する課題
 →差分移行をして、検証
・プロジェクト運営
プロジェクト管理、目的の共有と意思統一、レガシーシステムの改修要望に関する課題
 キックオフ・ミーティングの実施
  各社マネージメント及びプロジェクト関係者全員参加、目的の共有と医師の統一
 ステアリングコミッティの実施
  各社のマネージメント参加による、進捗・課題確認課題解決

マイグレーションアプローチ

既存のシステムの修正が必要な箇所を洗い出し
→修正内容でパターン分析
→分析結果からサンプルをピックアップして改修・テスト
→その結果を元に全てのプログラムを改修・テスト
→本番稼働

移行して得られたもの

・柔軟性
自由にスペックを変更。最低限のリソースを用意してできる
本番環境をそのままコピーして開発環境に出来る。不要なときは停止できる

・スピード
必要なリソースが必要な時必要なだけ調達できる

・コスト
初期投資不要。不要なサーバを立ち上げなければコスト抑制が可能

・セキュリティ
PHPのバージョンを上げられた。
VPCを導入することでセキュリティポリシーが統一された

・資産管理
資産管理不要になる

・運用担当者の負荷軽減
HW障害から開放されて、運用担当者の負荷が軽減される
インフラ担当者が少なかった為、その人がSPOFになってた

今後の取り組み

基幹システム
グループウェア
などAWSに移行すべきシステムがたくさんある

余談

AWSはドル建ての請求なので、円安の進行による請求額の上昇がある。これは想定外だった。

さいごに

なんかクラウドって心配、ということで敬遠される方が多い中、比較検討して導入する姿勢に敬服いたしました。
よく分からないという方にもわかっていただけるようなサービスを提供できるよう精進してきます。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.